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This is in response to the appeal brief filed on 3/20/07 appealing the final rejection of 
claims 3-4, and 7-8 from the Office action mailed on 10/24/06. 

(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct, 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 
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(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

6,332,058 Kawakami 12-2001 

6,028,632 Siong et al. 2-2000 

5,159,447 Haskell etal. 10-1992 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
1. Claims 3, 4, 7, and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kawakami of record (6,332,058) in view of Siong et al of record (6,028,632) and Haskell et al of 
record (5,159,447). 

Kawakami discloses an information reproduction apparatus as shown in Figures 1 and 2, 
and the substantially the same multiple decoding method for simultaneously decoding two or 
more encoded data from a broadcast signal composed of a plurality of encoded data (i.e. as 
provided by 12 of Figure 1, and see Figure 2, column 5, lines 55-65), and multiple decoding 
apparatus for receiving a broadcast signal composed of a plurality of encoded data and for 
simultaneously decoding two or more of the encoded data (i.e., as provided by 12 of Figure 1 and 
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see Figure 2, column 5, lines 45-65) as claimed in claims 3, 4, 7, and 8, comprising substantially 
the same selecting a plurality of decoders (i.e., 22 of Figure 2) for performing decoding and a 
plurality of separate buffers (i.e., 34 of Figure 2) corresponding to the plurality of decoders, 
respectively, according to the usage status of the plurality of decoders (i.e., gate controllers 32 
control writing of information to the respective decoder buffers 34 based on the usage of the 
decoders, and gate controllers 32 are being supplied flags EF for timing adjustments of the flow 
of data to the decoder, and the decoder will decoded the respective data when ready, see column 
5, lines 31-65, column 7, lines 7-47); extracting at least audio data and video data to be decoded 
and reproduced from the broadcasting signal (i.e., as provided by 18 of Figures 1 and 2, and see 
column 4, lines 47-60); storing at least the extracted audio data and video data in a buffer (i.e., 30 
of Figure 2); distributing at least the audio data and the video data stored in the buffer (i.e., as 
provided by 40 of Figure 2 and see column 5, lines 46-54, column 7, lines 7-18) for each data 
type (i.e., the MPEG stream of data as shown in Kawakami is based according to a specific type 
of video which includes inherent and specific header data, see column 5, lines 46-54, column 7, 
lines 7-18) and respectively storing at least the audio data and the video data in the plurality of 
separate buffers according to each data type (i.e., 34 of Figure 2); controlling output of at least 
the audio data and the video data stored in the separate buffers such that at least the audio data 
and the video data stored in the separate buffers are associated with each other (i.e., as provided 
by 32 of Figure 2 and see column 5, lines 31-45); decoding, responsive to the controlling, at least 
the audio and the video data stored in the separate buffers and outputting the two or more 
decoded data (i.e., as provided by 22 of Figure 2, and see column 5, lines 3 1-45); reproduction 
controller (i.e., 24, 36 of Figure 2) for outputting control information related to decoding and 
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reproduction of the data; a data extractor (i.e., MPEG core server 1 8 of Figures 1 and 2) for 
receiving the broadcasting signal and extracting at least audio data and video data which are 
designated by the control information; a buffer (i.e., 20, 30 of Figure 2) for storing at least the 
audio data and the video data extracted by the data extractor; a buffer manager (i.e., within core 
server 18 of Figures 1 and 2, and see column 5, lines 1-30) for controlling the buffer in 
accordance with the control information for the buffer; a data flow controller (i.e., 40 of Figure 2 
and see column 5, lines 46-54, column 7, lines 7-1 8) for distributing at least the audio data and 
the video data stored in the buffer for each data type and transferring at least the audio data and 
the video data in accordance with provided transfer conditions; a plurality of separate buffers 
(i.e., 34 of Figure 2) for respectively storing at least the audio data and the video data encoded 
data distributed and transferred by the data flow controller according to each data type; a 
plurality of decoders (i.e., 22 of Figures 1 and 2) respectively corresponding to the plurality of 
separate buffers for decoding at least the audio data and the video data stored in the plurality of 
separate buffers and outputting two or more decoded data; and a decoding controller for selecting 
a separate buffer and a decoder (i.e., CPU group 36 outputs control signal 38 in response to a 
request from external controller 24, thereby selecting the desired information for decoding to the 
respective buffer and decoder, see column 5, lines 46-54, column 7, lines 7-38) which are used 
for the decoding, according to the usage status of the decoder from among the plurality of 
separate buffers and the plurality of decoders in accordance with the control information (i.e., 
gate controllers 32 control writing of information to the respective decoder buffers 34 based on 
the usage of the decoders, and gate controllers 32 are being supplied flags EF for timing 
adjustments of the flow of data to the decoder, and the decoder will decoded the respective data 
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when ready, see column 5, lines 31-65, column 7, lines 7-47), and outputting information related 
to the separate buffer selected by the decoding controller, the transfer conditions based on the 
separate buffer selected by the decoding controller, and an instruction to start decoding, 
respectively, to the separate buffer manager, the data flow controller, and the decoder selected by 
the decoding controller (i.e., controller 24 and CPU group 36 controls all the hardware structures, 
see columns 5-7). Kawakami does not particularly disclose, though, the followings: (a) a separate 
buffer manager for controlling output of at least the audio data and the video data respectively 
stored in the plurality of separate buffers so as to be associated with each other in accordance 
with information for specifying the plurality of separate buffers as claimed in claims 3 and 4; (b) 
the separate buffer manger outputs, when a specific separate buffer becomes full of data, an 
overflow notification that the specific separate buffer overflows to the decoding controller, the 
decoding controller outputs, upon receipt of the overflow notification that the separate buffer 
overflows, an instruction to stop data transfer to the specific separate buffer to the data flow 
controller, an instruction to discard encoded data directed toward the specific separate buffer to 
the data flow controller, outputs an instruction to stop decoding to a decoder corresponding to the 
specific separate buffer, and outputs an instruction to initialize the specific separate buffer to the 
separate buffer manager, the separate buffer manager initializes the specific separate buffer in 
accordance with the instruction to initialize the specific separate buffer from the decoding 
controller without initializing the buffer, and the multiple decoding apparatus resumes all 
processing which was stopped as a result of the specific separate buffer becoming full after the 
specific separate buffer is initialized, and the discard of the encoded data is released after the 
specific separate buffer is initialized as claimed in claims 3 and 4; and (c) when a specific 
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separate buffer becomes full of data, discarding encoded data directed toward the specific 
separate buffer, stopping the distributing of at least the audio data and the video data into the 
specific separate buffer and the decoding of the encoded data stored in the specific separate 
buffer, initializing the specific separate buffer without initializing the buffer, and resuming all 
processing which was stopped when the specific separate buffer became full after the initializing 
of the specific separate buffer, and releasing the discard of the encoded data as claimed in claims 
7 and 8. 

Regarding (a), it is noted that Kawakami does teach the particular use of a plurality of 
buffer managers (i.e., 32 of Figure 2) for controlling the outputs of each of the respective 
plurality of separate buffers 34, but and not particularly a separate buffer manager for controlling 
the output of at least the audio data and the video data respectively stored in the plurality of 
separate buffers as claimed. However, Siong et al discloses a multiple buffer and video decoder 
management system as shown in Figure 1 , and teaches the general concept of the use of a 
separate buffer manager (i.e., 6 of Figure 1 and see column 3, line 56 to column 4, line 27) for 
controlling outputs of the plurality of separate buffers (i.e., 7-9 of Figure 1). Therefore, it would 
have been obvious to one of ordinary skill in the art, having the Kawakami and Siong et al 
references in front of him/her and the general knowledge of buffer management systems, would 
have had no difficulty in providing the separate buffer manager of Siong et al in place of the 
plurality of separate buffer managers 32 of Kawakami for the same well known single unit 
integrated processing and so that less hardware would be required for managing the buffers 
purposes as claimed. 
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Regarding (b) and (c), Haskell et al discloses a buffer control for variable bit rate channel 
as shown in Figures 1 -4, and teaches the conventional notification of overflow situations 
associated with encoder and decoder buffers (see column 17, line 66 to column 18, line 13), and 
the particular termination of packets of data within the decoder as one way of preventing 
overflow in the buffers, thereby stopping decoding to the decoder, data extraction, data transfer 
to the specific buffer, and discarding data directed toward the specific buffer (see column 16, 
lines 27-39). It is noted that Haskell et al is however silent as to the initialization of the specific 
separate buffer in response to the overflow notification without initializing the buffer and the 
subsequent resuming of the processing which was stopped when the specific separate buffer 
became full after initialization of the specific buffer and releasing the discard of the encoded data 
as claimed. But, it is considered obvious even without specific disclosure that once the packets 
are terminated within Haskell due to buffer overflow, the specific buffers of Haskell must be 
initialized since the exisfing data within the buffers are of no use and so that the buffers could be 
properly re-set. Such buffer initialization specifics as taught by Haskell may certainly be 
provided within Kawakami wherein the specific separate buffers 34 of Kawakami may also be 
initialized in response to an overflow notification. And it is considered obvious that since it is 
only necessary for the specific separate buffers 34 within Kawakami to be initialized in response 
to an overflow situation, the initialization of buffers 30 within Kawakami is obviously not 
necessary. Further, after such buffer initialization and re-setting within Haskell, all processing 
will therefore be resumed, and the discarded data is released (i.e., the existing data in the buffer 
is of no use and therefore is released) after buffer initialization. Therefore, it would have been 
obvious to one of ordinary skill in the art, having the Kawakami, Siong et al, and Haskell et al 
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references in front of him/her and the general knowledge of video encoder and decoder buffer 
fullness, would have had no difficulty in providing the overflow notification, termination of 
packets of data within the decoder as one way of preventing overflow in the buffers, thereby 
stopping decoding to the decoder, data extraction, data transfer to the specific buffer, and 
discarding data directed toward the specific buffer as taught by Haskell as well as the obvious 
initialization of buffers upon receipt of an overflow notification and the subsequent resuming of 
the processing which was stopped alter buffer initialization and the discard of the data is released 
after the buffer is initialized within Haskell for the multiple decoder of Kawakami so that the 
buffer manager, reproduction controller, decoding controller, and separate buffer manager of 
Kawakami may proper respond to the overflow notification for the same well known video 
decoder buffer overflow protection purposes as claimed. 

(10) Response to Argument 

II. Appellant's arguments filed in the Appeal Brief of 3/20/07 have been fiiUy considered but 
they are not persuasive. 

III. The Appellant presents eight substantive arguments contending Examiner Lee's rejection 
of claims 3, 4, 7, and 8 under 35 U.S.C. 103(a) as being unpatentable over Kawakami of record 
(US Patent 6,332,058 hereinafter referred to as "Kawakami") in view of Siong et al of record 
(US Patent 6,028,632 hereinafter referred to as "Siong") and Haskell et al of record (U.S Patent 
5,159,447 hereinafter referred to as "Haskell"), as was set forth in the Final Office action of 
10/24/06, and repeated above for the Board's convenience. However, after a carefiil 
consideration of the arguments presented, and further scrutiny of the applied references, the 
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Examiner must respectfully disagree and submit to the Board that the rejection is appropriate for 
the reasons that follow. 

IV. After establishing the legal basis of the arguments (Brief of 3/20/07: page 8, lines 1-3- 
14), highUghting the salient features of the claim language (Brief of 3/20/07: page 8, lines 15-29; 
page 14, lines 1-15), and providing a summary of the primary Kawakami reference (Brief of 
3/20/07: page 9, lines 1-29; page 10, lines 1-10; page 14, lines 14-29; page 15, lines 1-22), the 
Appellant argues that Kawakami 's MPEG server is different from the data extractor of the claims 
because Kawakami isn't directed towards handling a broadcast signal as in the instant invention 
(Brief of 3/20/07: page 10, lines 1 1-20; page 15, lines 23-29; page 16, lines 1-5). The Examiner 
respectfully disagrees. It is clearly noted that Kawakami discloses that the MPEG server is used 
for the transmission or reception of television broadcasts (Kawakami: column 15, lines 10-20), 
and therefore would encounter the same problem of overflow condition processing as in the 
claims (Kawakami: column 15, lines 25-30: "adjust the transfer rate coded information"). Also, it 
noted that data extraction would be obviously necessary to for the "editing" features of the 
disclosed MPEG servers in Kawakami. Accordingly, the Examiner maintains that since 
Kawakami is directed toward broadcast signal processing, it remains applicable to the claimed 
"data extractor" of the instant invention. 

Additionally, the Appellant argues that the Kawakami ". . .gate controllers. . ." are not 
capable of controlling the output rate of the decoder buffers and thus would not read upon the 
"separate buffer manager. . ." as in the claims (Brief of 3/20/07: page 1 0, lines 2 1 -29; page 1 1 , 
lines 1-20; page 16, lines 6-29; page 17, lines 1-4), as in the claim. The Examiner respectftally 
disagrees. It is noted that the gate controllers use the effectiveness flags to perform timing 
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adjustments to allow data to be passed through and decoded only while the decoder side is ready 
(Kawakami: column 7, lines 33-39). Such timing adjustments could not be performed without 
the gate controllers being able to control the outputting of the decoder buffers after ascertaining 
whether the decoders are ready to decode. Accordingly, since the gate controllers are shown to 
perform timing adjustments to the information flow processing, the Examiner maintains that they 
read upon the buffer manager part of the . .separate buffer manager. . limitation of the claims. 

In response to Appellant^s arguments against the references individually, one cannot 
show nonobviousness by attacking references individually where the rejections are based on 
combinations of references (Brief of 3/20/07: page 11, lines 3-8; page 16, lines 17-22). See In re 
Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 
USPQ 375 (Fed. Cir. 1986). In particular, since the Examiner has asserted that the . .data 
extractor. . and . .buffer manager. . limitations have been shown to be met by Kawakami, 
the secondary Siong and Kawakami references do not need to also show such features, and 
address those features with their combination with Kawakami. It is duly noted, however, that in 
certain particular instances discussed below, the Examiner asserts that Siong and Haskell also 
address certain features on their own. 

After summarizing the secondary Siong reference (Brief of 3/20/07: page 11, lines 9-20; 
page 16, lines 22-29; page 17, lines 1-4), and highlighting the incorporation the Siong reference 
with Kawakami (Brief of 3/20/07: page 11, lines 21-23; page 17, lines 5-7), the Appellant argues 
that the stated microcontroller of Siong also fails to read upon the . .separate buffer 
manager..." of the instant invention (Brief of 3/20/07: page 11, lines 24-29; page 12, lines 1-8; 
page 17, lines 1 1-23). The Examiner flatly disagrees. Firstly, as discussed above, the Examiner 
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has already shown that the "gate controllers" of Kawakami read on the . .buffer manager. . ." 
part of the limitation, so the Siong reference doesn't necessarily have to show the 
microcontroller also reading upon the buffer manager as in the claims. That being said, upon 
further scrutiny of Siong reference, the Examiner concludes that the microcontroller reads on 
. .buffer manager. . as in the claims as well. The Appellant argues that since Siong fails to 
disclose the use of the microcontroller in Siong in contemplation of buffer overflow, it fails to 
read upon the . .buffer manager. . as in the claims. The Examiner notes that the 
microcontroller is explicitly in control of header detection, said step whose sole object is to try to 
prevent overflow in the transmission buffer (Siong: column 3, lines 40-45) and overflow (Siong: 
column 4, lines 10-15) in the multiplexed buffers for each of the decoders (Siong: column 3, 
lines 59-61). Mechanisms for the prevention of overflow and underflow would seem to the 
Examiner as . .contemplations. . of buffer overflow situations (Siong: column 4, lines 10-15). 
So, as discussed herein, the Examiner would note that both the "gate controllers" of Kawakami 
and the "microcontroller" of Siong read on the ". . .buffer manager. . ." of the ". . .separate buffer 
manager. . ." the claims. Now, we come to the "separate" part of the limitation. It is noted that 
Examiner Lee's incorporation of Siong with the primary Kawakami reference was that Siong's 
singular "separate buffer manager" of the microcontroller would replace the plurality of 
"separate buffer managers" of the ". . .gate controllers. . ." in Kawakami in order to reduce the 
scale of the apparatus to reduce power consumption (i.e. less hardware). Based on the 
Examiner's assertion that both elements control buffer throughput in video processing systems, 
one of ordinary skill in the art would look to combine the teachings of Siong with Kawakami if 
an obvious advantage could be achieved. Siong connotes such an advantage to Kawakami (i.e. to 
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make something integral which was once separate), and it is duly noted that this particular 
modification has been summarily determined to unpatentable by the courts, In re Larson. 144 
USPQ 347 (CCPA 1965). & In re LockharL 90 USPQ 214 (CCPA 1951). Accordingly, the 
Examiner submits that the "separate buffer manager" limitation is met by the pending 
incorporation of Siong with Kawakami. 

Furthermore, the Appellant argues that Siong fails to disclose the use of a "data 
extractor" as in the claims (Brief of 3/20/07: page 12, lines 9-11; page 17, lines 23-25). The 
Examiner respectfully disagrees. It is noted that although the signal is stored in a transmission 
buffer, undergoes header extraction after detection (Siong: column 3, lines 34-45) which would 
read upon the "data extractor", and then is stored in multiplexed buffers for each decoding unit 
(Siong: figure 2, element 13). It is the header detection and multiplexing unit and the multiplexed 
buffers which read upon the data extractor and buffer in the claims. Accordingly, the Examiner 
asserts that Siong on its own, also address the "data extractor" as in the claims. 

Additionally, the Appellant argues that Siong reference fails to disclose the claimed 
decoding controller, since it fails to consider the occurrence of a buffer overflow (Brief of 
3/20/07: page 12, lines 12-16; page 17, lines 26-27; page 18, lines 1-2). The Examiner 
respectftilly disagrees. There appears to be a fundamental disagreement as to whether 
". . .overflow prevention. . ." as in Siong is sufficient to anticipate actual ". . .overflow 
occurrence. . ." as argued. If the Examiner is to understand the Appellant's stance, it would 
appear that the Appellant believes that since Siong or Kawakami doesn't actually let the 
overflow condition happen, they aren't actually directed towards overflow processing as 
claimed. The Examiner would note that although overflow prevention is in place, and that the 
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stated aim of Siong would be ensure that any overflow is to avoided, this doesn't mean that those 
measures work perfectly all the time. Even with these measures in place, the "overflow problem" 
will still occur (Siong: column 4, lines 60-65). Preventative measures may be implemented to the 
fullest degree and the undesired result can still occur due to instantaneous changes in the 
bandwidth availability (Siong: column 4, lines 47-50). The measures are in place due to the fact 
that the bandwidth variations are left unchecked, overflow situations would occur with an 
unacceptable severity and frequency, but with the measures in place, overflow conditions would 
occur in a fashion that is manageable. As such, the Examiner asserts that "overflow 
prevention. . ." would be "overflow processing. . as in the claims. 

Furthermore, after providing a summary of the applied Haskell reference (Brief of 
3/20/07: page 12, lines 17-26; page 18, lines 3-13), the Appellants argue that since Haskell is 
also directed towards "overflow prevention. . as opposed to "overflow occurrence 
processing. . as in the instant invention, and thus the claims distinguish over Haskell (Brief of 
3/20/07: page 13, lines 1-7; page 18, lines 14-23). The Examiner respectfully disagrees. Most of 
this argument has been discussed above with regards to the Siong reference, but the Examiner 
further asserts that in Haskell, there are specific protocols in place for overflow occurrences 
(Haskell: column 16, lines 30-40). The Examiner notes that Haskell employs such actions to 
". . .alleviate overflow, . (Haskell: column 16, lines 28-30) which to the Examiner establishes 
the fact that decoder buffer overflow has occurred in spite of disclosed preventative measures 
(Haskell: column 9, lines 15-51). As such, the Examiner would assert that Haskell, on its own, 
addresses ". . .overflow occurrence processing. . as in the claim, since it has protocols in place 
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specifically for such occurrences, if". . .overflow prevention. . ." is not seen to address "overflow 
occurrence processing. . ." as discussed above. 

Lastly, the Appellant argues that Haskell fails to disclose ". . .an overflow notification. ..." 
as in the claims (Brief of 3/20/07: page 13, lines 7-29; page 18, lines 24-29; page 19, lines 1-19). 
The Examiner respectfully disagrees. First, one of ordinary skill in the art would note that 
Haskell discloses the use of a decoder pack signal to inform the Haskell encoder of an overflow 
occurrence (Haskell: column 17, lines 49-65) especially since the reference discloses a decoder 
buffer counter to track "worst case behavior. . ." (i.e. "overflow occurrences"). So the Examiner 
would assert that Haskell sufficiently discloses an ". . .an overflow nofification. . as in the 
claims. As to the specific instructions, it is noted Haskell would address stopping a data transfer 
(Haskell: column 16, lines 27-31 : packet termination), initializing a specific buffer (Haskell: 
column 18, lines 1-10: "presetting a threshold"), and Siong would address stopping a decoder 
from decoding (Siong: column 4, lines 5-11: micro-controller deactivating/activating the 
decoders). As such, the Examiner maintains that the references as combined address ". . .an 
overflow notification. . ." as in the claims. 

There appear to be no additional arguments individually concerning claims 7 and 8, and 
therefore, for the reasons discussed above conceming claims 3-4, the Examiner submits to the 
Board that these claims should be rejected, as well. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 
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Conclusion 

For the above reasons, it is believed that the rejections should be sustained. 



Respectfully submitted. 
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